The alternate-signal-stack free list is a deliberate process-wide cache
(uniform stacks reused across guest threads), so the global count for
litebox_platform_linux_userland goes from 5 to 6.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01End2XtfTCUfUyZsyAU8NsU

The guest/host transition and signal-handler code read and write the
fs/gs bases with rdfsbase/wrgsbase, which #UD (SIGILL) unless the host
has CR4.FSGSBASE set. Some hosts lack it — old CPUs/kernels, hosts
booted with `nofsgsbase`, and PVM (pagetable-based VM) guests on such
hosts. The previous commit failed fast there; instead, detect FSGSBASE
once at startup (AT_HWCAP2) and branch each fs/gs access:

- native path: unchanged rdfsbase/wrgsbase/rdgsbase/wrfsbase
- fallback path: arch_prctl(ARCH_GET/SET_FS/GS) syscalls, with the host
  fs base cached in a new `host_fsbase` TLS slot so the syscall-return
  path can restore it without an FSGSBASE read

The transition assembly saves the full guest register frame before
restoring the host fs base so the fallback syscalls may clobber
caller-saved registers and flags freely; the entry path reloads the
thread-context pointer (clobbered by the arch_prctl arguments) from the
stack before calling the handlers. arch_prctl is added to the seccomp
allowlist (thread-local fs/gs only, sandbox-neutral). Setting
LITEBOX_NO_FSGSBASE forces the fallback for testing on capable hosts.

RDTSCP is not used by LiteBox, so no equivalent is needed; guest use of
RDTSCP is governed by the guest's own CPUID/auxv view.

Verified: full runner + shim + platform suites pass identically with and
without LITEBOX_NO_FSGSBASE (only the pre-existing diod/python
environmental failures remain), in debug and release.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01End2XtfTCUfUyZsyAU8NsU

When a leaf PTE is created on demand, the CPU's page-table walker sets
the ACCESSED bit on first access (and DIRTY on first write) with a
locked, microcoded write that takes the PTE cache line for exclusive
ownership. Pre-filling the software-known result avoids that write,
reducing cache-coherency traffic and slightly speeding up the walk —
the same optimization Linux applies via pte_mkyoung()/pte_mkdirty() on
fault-in.

In vmflags_to_pteflags (linux_kernel and lvbs x86 platforms), leaf PTEs
are now built ACCESSED, and writable leaves additionally DIRTY (DIRTY is
only ever set together with WRITABLE). Intermediate table entries
created during the walk also get ACCESSED (matching Linux's _PAGE_TABLE;
DIRTY is meaningless on non-leaf entries and is omitted).

This is behavior-neutral: MPROTECT_PTE_MASK excludes A/D so mprotect
neither observes nor clears them, and no code reads A/D for data pages
(CoW/reclaim are unimplemented). Verified: linux_kernel clippy + mm
tests pass (4/4), lvbs clippy clean on stable.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01End2XtfTCUfUyZsyAU8NsU

From a multi-lens review of the earlier optimization commits:

- futex: resolve the wake-vs-timeout race in favor of the wake. A waiter
  whose wait_until reported a timeout/interruption at the same moment a
  concurrent wake/requeue selected it (consuming that wakeup) now returns
  Ok once its entry is removed and `done` is observed set, instead of
  dropping the wakeup. remove() synchronizes with the waker's release of
  the entry, so `done` is stable at that point. Matches Linux futex_wait.
- futex: document that FUTEX_CMP_REQUEUE's value compare is not held under
  the source bucket lock — benign for its only consumer (POSIX condvar
  broadcast), where a stale pass yields at most a spurious wakeup, never a
  lost one, since waiters re-check the word under the lock before parking.
- shim write: writes larger than the 512KiB scratch buffer fall back to a
  single owned copy + single sys_write, preserving datagram message
  boundaries and O_APPEND atomicity (chunking would fragment them); mirrors
  the existing sys_sendto guard. Sub-512KiB writes keep the buffer reuse.
- platform: cache num_cpus (available_parallelism) once, seeded before the
  seccomp filter is installed, so sched_getaffinity no longer re-probes the
  host on every call.
- errno: mmap of a directory or non-regular fd now reports ENODEV (Linux's
  "mmap not supported by this file"), not EISDIR.

Verified: fmt/clippy(-Dwarnings)/build clean; litebox + shim + common +
platform + runner + dev_tests suites pass (only the pre-existing diod/9P
and python environmental failures remain).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01End2XtfTCUfUyZsyAU8NsU

A follow-up review escalated the earlier note on requeue()'s value
compare: performing it as an unlocked read (separate from the requeue
scan) is not merely a spurious-wakeup risk but can strand a waiter. If a
waiter enqueues on the source word with the new value between the check
and the scan, it can be requeued onto the target word based on a stale
comparison; because requeue does not mark the target word contended, a
later uncontended unlock issues no FUTEX_WAKE and the waiter hangs. Linux
avoids this by comparing the word under the hash-bucket lock.

Add LoanList::extract_if_guarded, which runs a guard closure under the
list lock before any entry is examined or removed, and rewrite requeue()
to validate the futex word through it while scanning the source bucket
first — so a mismatch aborts with EAGAIN and zero side effects, and the
check is atomic with the requeue against concurrent enqueues on the same
word. extract_if now delegates to the guarded form with a no-op guard.

Also document the displaced-counter fast-path limitation (a parked
cross-bucket-requeued waiter forces all-bucket wake scans) as a known,
correctness-neutral perf tradeoff rather than risk a lost wakeup from a
per-bucket accounting scheme.

Verified: fmt/clippy(-Dwarnings)/doc clean; litebox + shim suites pass
(incl. test_futex_requeue, which now exercises the locked value check);
only the pre-existing diod/9P environmental failures remain.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01End2XtfTCUfUyZsyAU8NsU

Independent security/reliability audits (unsafe-code soundness, sandbox
boundary integrity, integer/bounds safety, guest-reachable panics,
resource lifecycle) surfaced real, guest-triggerable defects. Fixed the
ones confirmed by direct code reading, most severe first:

- CRITICAL, sandbox escape: anonymous RW memory written with a raw
  `syscall` opcode and mprotect'd executable ran unmediated on the host
  — the runtime syscall-rewriter only ever tracked file-backed exec
  segments (`elf_patch_cache`'s `file_mappings`), never anonymous
  mappings. `sys_mprotect` now falls back to the existing
  `apply_trap_fallback` byte-scanner (already used for unpatchable file
  segments) whenever no tracked file mapping accounts for the range
  gaining PROT_EXEC. Verified against Node's V8 JIT (RW<->RX toggling is
  the common, legitimate case) — correct but not free: ~44ms slower
  Node startup, an accepted, necessary cost of closing a real escape.
  Simultaneous PROT_READ_WRITE_EXEC still can't be fully defended (no
  permission-transition event to hook); documented as a residual,
  pre-existing risk in PageManager::make_pages_rwx's own safety comment.

- CRITICAL, guest-controlled host-ASLR leak / control-flow-hijack
  primitive: `rt_sigreturn` copied a guest-memory-supplied `rip`/`rsp`/
  `eflags` into the resume context with no validation, then
  unconditionally `jmp`'d to it. A non-canonical `rip` faults inside the
  host's own transition code and leaks that host address into the
  guest's signal handler; a valid host code address plus a
  guest-controlled stack is a jump-into-trusted-code primitive. The
  `lvbs`/`snp` platforms already gate every guest resume on
  `PtRegs::sanitize_for_user_return()`; wire the same call into
  linux_userland's single guest-resume choke point
  (`ThreadContext::call_shim`), terminating the thread instead of
  resuming with invalid state.

- CRITICAL, arbitrary host munmap: `mremap`'s `new_size` only passed
  through `checked_next_multiple_of(PAGE_SIZE)`, which accepts an
  already-page-aligned huge value unchanged; `resize_mapping` then added
  it to the mapping's start address with a raw `+`, and a guest-chosen
  wraparound could make the "shrink" branch unmap an arbitrary
  attacker-chosen range instead of a suffix of its own mapping. Use
  `checked_add`, rejecting the call instead of wrapping.

- HIGH: an ordinary `dup2`/`fcntl(F_DUPFD)` to a fd number past a small,
  undocumented internal growth bound (`stored_fds.len() + 256`) hit a
  hard `assert!` — reachable with ordinary target fd numbers on a fresh
  process, independent of the real `RLIMIT_NOFILE` check already in
  place. Converted to a graceful decline propagated as `ENOMEM`/
  `EMFILE`, correctly distinguishing it from `do_close_and_replace`'s
  pre-existing `EBADF` return-as-side-effect for "nothing to close."

- HIGH: `mmap`'s reserved-space and range math used raw `+` on
  guest-controlled lengths, wrapping (silently, in
  `NonZeroPageSize::Add`) or panicking (via `.unwrap()` on the resulting
  `PageRange`) instead of erroring. Switched to `checked_add` throughout,
  surfacing `AllocationError::OutOfMemory` instead of a crash.

- HIGH: the sole network worker thread `unimplemented!()`'d on ANY
  `send_ip_packet` errno, including `EAGAIN`/`EWOULDBLOCK` from the
  non-blocking TUN fd under ordinary backpressure — no malicious input
  needed, just network load — killing networking process-wide. Added
  `SendError::WouldBlock` (mirroring the existing `ReceiveError`) and
  taught `TxToken::consume` to drop the packet on backpressure, exactly
  as a real NIC driver would; TCP retransmission handles recovery.

- LOW: an unguarded subtraction in `AF_UNIX` sockaddr encoding
  (`addrlen_val - offset`) could underflow given a guest-supplied
  `addrlen` at or below the path field's offset; guarded to match the
  sibling `Abstract`-address arm.

Verified: fmt/clippy(-Dwarnings)/doc clean; full workspace test suite
matches the pre-existing environmental-failure baseline exactly (20
known diod/9P/python failures, zero new ones) after eliminating
tun-device contention from a stray background process; Node.js runs
correctly under the anonymous-exec-scan path.

Several further confirmed findings (a `create_pages` TOCTOU allowing a
concurrent thread to corrupt a just-created mapping; an ELF-loader
integer overflow in segment-reservation math; an unbounded `to_cstring`
scan; execve leaking PageManager state on a partially-loaded image;
`bind`/`listen`-after-`connect` corrupting the shared local-port
allocator; an unpatched `path.rs` `..`-at-root normalization gap) are
real but not fixed in this pass — each needs more invasive redesign
(lock restructuring, rollback-on-failure semantics) than is safe to rush
alongside this batch; left for follow-up.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01End2XtfTCUfUyZsyAU8NsU

…aba-tl6lcg

Claude/ultracode perf x86 alibaba tl6lcg